I am used to sendmail and am using Postfix now and am uncertain of some
features. I typically would comment out the line in sendmail.mc that
went something like 'accept unresolvable domains'
I tried using
smtpd_sender_restrictions reject_unverified_sender
reject_unverified_smtp
and this seems a bit too restrictive and got some bounces on legitimate
senders
so I'm thinking that this is perhaps a bit more apropos...
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_hostname
does this make sense?
Craig
Personally, I reject mail from any server with broken DNS. It's
extremely low hanging fruit to avoid a lot of spam from zombie PCs in
Asia/Eastern Europe. You also might want to consider using the various
freely available RBL sites to eliminate known naughty hosts/networks.
After mail runs this gauntlet, I pass it through CRM114 and have reduced
the spam that makes it to my mailbox to a couple of messages a week.
Here's the relevant lines from my postfix config:
maps_rbl_reject_code = 571
smtpd_helo_required = yes
smtpd_delay_reject = no
allow_untrusted_routing = no
disable_vrfy_command = yes
#
maps_rbl_domains relays.ordb.org,
opm.blitzed.org,
list.dsbl.org,
sbl.spamhaus.org,
cbl.abuseat.org,
dul.dnsbl.sorbs.net
smtpd_recipient_restrictions reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_maps_rbl,
permit
smtpd_data_restrictions reject_unauth_pipelining,
permit
stale_lock_time = 120
default_rbl_reply = $rbl_code Service denied; blocked
Good luck,
C
Craig White wrote:
>I am used to sendmail and am using Postfix now and am uncertain of some
>features. I typically would comment out the line in sendmail.mc that
>went something like 'accept unresolvable domains'
>
>I tried using
>
>smtpd_sender_restrictions > reject_unverified_sender
> reject_unverified_smtp
>
>and this seems a bit too restrictive and got some bounces on legitimate
>senders
>
>so I'm thinking that this is perhaps a bit more apropos...
>
>smtpd_helo_restrictions =
> permit_mynetworks,
> reject_invalid_hostname
>
>does this make sense?
>
>
>
> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of RNuno > Sent: Friday, April 01, 2005 4:12 PM > To: CentOS mailing list > Subject: Re: [CentOS] postfix tightening > > Ajay Sharma wrote: > > >I run an "office" mail server and my boss would kill me if > we bounced a > >message just because the client is using a brain dead ISP. So our > >approach is a little different in that we accept a lot of mail and I > >spend my time on tuning spamassassin. > > > > > > > Same here. We cannot going on rejecting every server that > don't reverse I'ts not that I would like to but the truth is > MANY companies have them.I have never understood the precived connection between reverse DNS and spam. I have seen some go as far as if the reverse DNS does not match the senders domain they will kick it. I am all for blocking spam, but it is a fine line to block it without being an ass and catching all kinds of legitimate mail in the process. Perfect example is the one RBL that will list entire ISPs until the sufficently grovel in their newsgroup, all the while not caring that this is impacting hundreds or thousands of servers that are not spamming or supporting spam. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
<snip>> > I have never understood the precived connection between reverse DNS > > and spam. I have seen some go as far as if the reverse DNS does not > > match the senders domain they will kick it. > ---- > it doesn't seem to be too difficult to have the smtp server > helo to be locatable in reverse dns - the thing that this > blocks is people running smtp servers on dynamic ip space and > forces them to use a smart host - can't see what the big deal > is here since it provides accountability for the mail path.It's not a matter of difficult, nor does it provide any accountability. I can tell my mail server to helo whatever I want and make the ptr say whatever I want. It doesn't authenicate anything. Nor does someone running an SMTP server with a dynamic address prove anything about it being spam. The big problem that I have with it is that it completely ignores shared hosting. Not everyone wants someone to be able to look at the mail headers and know what company is hosting them, particularly a business. There are plenty of legitimate reasons to not have it.> Now that AOL is doing this, it pretty much dictates that smtp > servers comply with this restriction. I don't see the problem with it.So, you are saying that we should let AOL dictate standards? I see a HUGE problem with that. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> On Fri, 2005-04-01 at 20:19 -0600, Mark A. Lewis wrote: > > I have never understood the precived connection between reverse DNS > > and spam. I have seen some go as far as if the reverse DNS does not > > match the senders domain they will kick it. > > Mostly because a trojaned machine on a broadband connection > spewing SPAM will not have a valid reverse DNS entry.Riight. Ever done a reverse lookup on a RR IP? Rogers? SBC? All of them will have valid reverse entries.> By forcing a policy of accurate reverse DNS, most of the > home-broadband- SPAM factories are shut down.I would argue that using that logic none of them will be shut down. Not trying to pick any fights here, I just feel very strongly that the logic is very flawed and am looking for some real justification of this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of > ryanag at zoominternet.net > Sent: Friday, April 01, 2005 9:24 PM > To: CentOS mailing list > Subject: RE: [CentOS] postfix tightening > > On Fri, 2005-04-01 at 21:04 -0600, Mark A. Lewis wrote: > > > > Riight. Ever done a reverse lookup on a RR IP? Rogers? SBC? All of > > them will have valid reverse entries. > See below. > > http://searchcio.techtarget.com/sDefinition/0,,sid19_gci917504,00.html > > "Reverse DNS (rDNS) is a method of resolving an IP address > into a domain > name, just as the domain name system (DNS) resolves domain names into > associated IP addresses. One of the applications of reverse > DNS is as a > spam filter. Here's how it works: Typically, a spammer uses an invalid > IP address, one that doesn't match the domain name. A reverse > DNS lookup > program inputs IP addresses of incoming messages to a DNS database. If > no valid name is found to match the IP address, the server blocks that > message."So, here is the problem. Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget would rather not have mail.hostco.com in the mail headers for whatever reason. So, hostco doesn't setup a ptr record for it. This does not make Acme Widget or Hostco any more likely to be spammers, it just makes you more likely to drop their mail. Now, the other side of that... Foospam wants to send out 87 bazillion mail messages to everyone about fooagra. So, they set their mail server to helo with fooco.com and set the ptr record to be mail.fooco.com and they just danced right by all of this with very minimal effort. For that matter, you can use whatever ptr your ISP sets up for you. The whole accountablity thing is a fallacy. I can buy a domain right now for $8, put whatever I want in the whois info and just use that for the ptr record part, it could be a throwaway domain for all I care. At the end of the day, it bought the person reciving the spam nothing. Reverse DNS or not, you can see what IP the mail came from, you can tell who is the owner of that IP and they can find out what user has that IP. The problem is that most of them are simply unwilling to do so, they ignore mail to the abuse address or just give you a canned answer. My point is that relying on this only makes you more likely to drop legit mail and poses no problem to the spammers. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>Tom Ivar Helbekkmo writes: > >"Mark A. Lewis" <mark at siliconjunkie.net> writes: > >> Lets say that Acme Widget has their mail hosted with Hostco. Acme Widget >> would rather not have mail.hostco.com in the mail headers for whatever >> reason. So, hostco doesn't setup a ptr record for it. This does not make >> Acme Widget or Hostco any more likely to be spammers, it just makes you >> more likely to drop their mail. > >Actually, the problem you're describing is routinely solved at any >decent ISP *without* breaking any rules. If the above were a genuine >scenario, I would conclude that Hostco is run by nincompoops. ;-)For the posterity of the list, and the wonderful information that's been provided so far for all of the newbie nincompoops out in CentOS list lurker-land ... Let's say that I'm a nincompoop newbie sysadmin from HostCo that would like to avoid breaking any rules. (In reality, I'm a PHB, and I let my sysadmin worry about the rule-breaking.) How would I go about providing a good, solid *matching* ptr (as in, mail from AcmeWidget.com reflects to mail.AcmeWidget.com at x.x.x.219 ... which also happens to be mail.hostco.com) for the bazillion and one virtual-hosted email accounts on mail.hostco.com? -Karl Katzke
> Wrong. RFC2821 says: > > 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) > > These commands are used to identify the SMTP client to the SMTP > server. The argument field contains the fully-qualified > domain name > of the SMTP client if one is available. In situations in which the > SMTP client system does not have a meaningful domain name > (e.g., when > its address is dynamically allocated and no reverse > mapping record is > available), the client SHOULD send an address literal (see section > 4.1.3), optionally followed by information that will help > to identify > the client system. The SMTP server identifies itself to the SMTP > client in the connection greeting reply and in the response to this > command. > > > Cheers, > GavinIt specifically mentions that dynamic addresses are acceptable. It specifically states that there are alternatives (an address literal) RFC 2821 also says: There are two exceptions to the rule requiring FQDNs: - The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1. So, it seems to me that the RFC compliant way to do this is to use the literal address in the HELO Meaning that those who reject this are the non RFC compliant ones... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>There is certainly nothing there > to override the earlier RFC (which I've forgotten) that > specifies a similar recommendation but goes on to say that > the receiver MUST NOT reject the message based on an address > lookup mismatch for the HELO/EHLO name (obviously written by > someone who realized that multi-homed servers are common and > that corporate servers often live behind NAT firewalls and > don't even know the address that will be used the public side). > > -- > Les Mikesell > les at futuresource.comI believe you are referring to RFC 821: The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Stumbled across this while researching the points raised in this thread. Very good writeup IMO and addresses many of the questions/concerns. http://jimsun.LinxNet.com/misc/postfix-anti-UCE.txt -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> On Saturday 02 April 2005 05:32 pm, karl at streetlampsoftware.com wrote: > > > How > > would I go about providing a good, solid *matching* ptr (as > in, mail > > from AcmeWidget.com reflects to mail.AcmeWidget.com at x.x.x.219 ... > > which also happens to be mail.hostco.com) for the bazillion and one > > virtual-hosted email accounts on mail.hostco.com? > > You wouldn't. That's not and never was the purpose of a ptr record. > The ptr record is to attach responsibility for the IP#. > That's done by pointing it to the hostname.But, in this case, it has multiple hostnames, all of which are valid.> You could have multiple ptr records, but there exists no > facility in any DNS or resolution system to match up ptr > records with a records. If I recall correctly, behavior in > the case of multiple ptr records is undefined.Interesting, never tried creating multiple ptr records. I guess if the MTA knew how to deal with that it would be a very good solution. I will have to do some testing to see how it reacts to the scenario. It all comes back to a few key points: 1) Refusing mail based on HELO not matching the ptr record is not RFC compliant, but it is not uncommon. 2) There are some vanity issues with someone who cares what the mail headers say in them. As someone else said, if they are expecting that, they should expect to pay for it. 3) All of the RFCs pertaining to this were written in a much more trusting time, and as we are seeing, they need to be revisited. 4) There are some easy to do HELO checks that can eliminate a large number of spammers and misconfigured MTAs. I do think that the RFCs need to address dynamic address space more sufficently. I think that the one proposal where the source IP must be listed under a particular record type in DNS will go a long way towards addressing many of these issues. IMO, none of the cost based solutions I have read such as "postage" or something mildly CPU intensive will accomplish anything but a mess. Good discussion though, I have learned a lot by actually reading some of the RFCs and some dicussions on them. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.