Discuss

discuss@lists.centos.org

1 participants
34730 discussions

RE: [CentOS] Re: postfix tightening
by Mark A. Lewis 04 Apr '05

04 Apr '05

> On Saturday 02 April 2005 05:32 pm, karl(a)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.

3 2

Re: postfix tightening
by karl＠streetlampsoftware.com 03 Apr '05

03 Apr '05

>Tom Ivar Helbekkmo writes: > >"Mark A. Lewis" <mark(a)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

3 2

RE: [CentOS] Re: postfix tightening
by Mark A. Lewis 03 Apr '05

03 Apr '05

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.

2 1

CentOS 3.4 to CentOS 4
by Jason 03 Apr '05

03 Apr '05

I have upgraded to CentOS 4 from 3.4. I am having trouble figuring out the mail changes. Under 3.4, Imap and POP were modules that xinetd controlled. Under 4.0, I have a choice of either Cyrus-Imapd or Dovecot. After googling all week, I was about to get my user account authenticated under Cyrus and the saslpasswd program, as well as dovecot. My problem is that they don't know where my mail is. I run postfix, and have mail delivered to /var/spool/mail/%u. I put this into Cyrus' mail directory but it still doesn't see anything. Dovecot always tries to chdir to the user's home directory, ignoring anything I put into dovecot.conf concerning mail locations. Any ideas? Thanks.

1 0

RE: [CentOS] postfix tightening
by Mark A. Lewis 03 Apr '05

03 Apr '05

> -----Original Message----- > From: centos-bounces(a)centos.org > [mailto:centos-bounces@centos.org] On Behalf Of > ryanag(a)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.

7 9

RE: [CentOS] Re: postfix tightening
by Mark A. Lewis 03 Apr '05

03 Apr '05

>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(a)futuresource.com I 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.

1 0

RE: [CentOS] Re: postfix tightening
by Mark A. Lewis 03 Apr '05

03 Apr '05

> 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, > Gavin It 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.

1 0

CentOS4 laptop touchpad erratic operation
by Collins Richey 02 Apr '05

02 Apr '05

I've just put up CentOS4 on my HP ze4630us laptop, and the installation produced only two problems of note, both related to X operations. 1. The installer refused to allow 1024x768 resoultion for the screen. After install, manually setting the resolution in xorg.conf was no problem. 2. Erratic touchpad operation. This unit has a synaptic touchpad. I've also noted similar problems on my previous Gentoo install (also 2.6 kernel and xorg). Never really resolved this. When scrolling across a screen in a browser panel where there are multiple links, the mouse will trigger click operations all on its own, so it's difficult to reach the link you want without inadvertently opening another link that you scroll past. In googling, I didn't have much luck finding a matching problem; nor did I have much luck earlier. Most of the problems reported seemed to be "touchpad unable to respond to clicks", i.e. the opposite of my problem. The installer generated the following mouse definition in xorg.conf: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" EndSection Has anyone else seen this type of problem with a touchpad, and does anyone have knowledge of a fix? TIA, -- Collins When I saw the Iraqi people voting three weeks ago, 8 million of them, it was the start of a new Arab world.... The Berlin Wall has fallen. - Lebanese Druze leader Walid Jumblatt

2 3

mkbootdisk!
by israel.garcia＠cimex.com.cu 02 Apr '05

02 Apr '05

I'm trying to make a bootdisk in my CentOS server and I got this error.. any ideas? [root@server:~]$ rpm -qa kernel kernel-2.6.9-5.0.3.EL [root@server:~]$ mkbootdisk 2.6.9-5.0.3.EL --device /dev/fd0 Insert a disk in /dev/fd0. Any information on the disk will be lost. Press <Enter> to continue or ^C to abort: cp: writing `/tmp/mkbootdisk.d20227/initrd.img': No space left on device cat: write error: No space left on device cat: write error: No space left on device 20+0 records in 20+0 records out I have enogh space on the disk: [root@server:~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/md5 17G 1.8G 14G 12% / /dev/md1 99M 8.4M 86M 9% /boot none 126M 0 126M 0% /dev/shm /dev/md3 9.7G 2.7G 6.5G 30% /home /dev/md0 981M 26M 905M 3% /usr/local/salva /dev/md4 4.9G 262M 4.4G 6% /var/log /dev/md2 981M 24M 908M 3% /var/spool regards, Israel

2 1

CentOS-announce Digest, Vol 2, Issue 1
by centos-announce-request＠centos.org 02 Apr '05

02 Apr '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CentOS-4 ia64 errata: Important: gtk2 security update (Pasi Pirhonen) 2. CentOS-3 ia64 errata: Important: gtk2 security update (Pasi Pirhonen) 3. CESA-2005:354 Moderate CentOS 3 ia64 tetex - security update (Pasi Pirhonen) 4. CESA-2005:344: Important CentOS 3 i386 gtk2 - security update (Tru Huynh) 5. CESA-2005:344: Important CentOS 3 x86_64 gtk2 - security update (Tru Huynh) 6. CESA-2005:354: Moderate CentOS 3 x86_64 tetex - security update (Tru Huynh) 7. CESA-2005:354: Moderate CentOS 3 i386 tetex - security update (Tru Huynh) 8. CESA-2005:344 Important CentOS 3 s390(x) gtk2 - security update (Pasi Pirhonen) 9. CESA-2005:344 Important CentOS 4 i386 and x86_64 gtk2 - security update (Johnny Hughes) 10. CESA-2005:354 Moderate CentOS 3 s390(x) tetex - security update (Pasi Pirhonen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 1 Apr 2005 23:31:02 +0300 From: Pasi Pirhonen <upi(a)iki.fi> Subject: [CentOS-announce] CentOS-4 ia64 errata: Important: gtk2 security update To: centos-announce(a)centos.org Message-ID: <20050401203102.GA9816(a)core.upi.iki.fi> Content-Type: text/plain; charset="us-ascii" Security update for CentOS 4 ia64 https://rhn.redhat.com/errata/RHSA-2005-344.html The following updated files have been uploaded and are currently syncing to the mirrors: ia64: updates/ia64/RPMS/gtk2-2.4.13-14.ia64.rpm updates/ia64/RPMS/gtk2-devel-2.4.13-14.ia64.rpm -- Pasi Pirhonen - upi(a)iki.fi - http://iki.fi/upi/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss