Mailing List Archive

1 2  View All
Re: (no subject) [ In reply to ]
Hello Ronnie,

Ronnie Tash, 25.09.2005 (d.m.y):

> when installing mysql when i run this command $chown -R mysql:mysql
> /var/db/mysql it tell me
> chown: /var/db/msql: No Such file or directory
> any body out there pliz help.

Go and buy a "y". ;-)
The path is /var/db/mysql and not /var/db/msql.

Regards,
Christian Schmidt

--
Nouvelle Cuisine heißt gewöhnlich: Zuwenig auf dem Teller und zuviel
auf der Rechnung.
-- Paul Bocuse
Re: (no subject) [ In reply to ]
Michael Peek wrote:
> Hello exim users.
>
> I have an ACL question for you guys. It's more of a policy question than
> a technical question. I would like to deny hosts whose
> $sender_helo_name/address doesn't match their $sender_host_name/address.
> I started off with the following in my acl_smtp_mail ACL:
>
<SNIP>
> This is probably a terrible hack job that will make more knowledegable
> gurus cringe, but it worked... sort of. This still denies some things
> like
> eagle.colostate.edu [129.82.103.90] as not being "close enough" to
> eagle.acns.colostate.edu [129.82.100.90].
>
> Before I go much farther with this (like dropping the required "closeness"
> from 24 bits to 16 bits -- all I really care about is that the remote host
> isn't obviously lying), what clever things have you guys implemented?
>
> I suppose it would be nice to be able to look up the owner of both
> addresses in whois and check to see if they're both in the same block, but
> my guess is that's darned near impossible to automate, what with whois
> being broken up and deregulated and all.
>
> Is there a rule in the SMTP protocol that says the HELO name has to match
> the remote sender's hostname/address in some way?
>
> Maybe I should just chuck it out the window?
>
> Whaddaya think sirs?

According the RFC, you're not supposed to block because of a 'bad'
HELO/EHLO. However, I think most of us would agree that there some
cases where it is useful. But I would recommend keeping it simple.

At our site we reject if the incoming HELO/EHLO is:

1) Our hostname
2) Our IP address (in the legal format [IP])
3) A bare IP

If the HELO/EHLO cannot be verified, we do a delay of 20 secs in the
connect and helo phases. These delays catch a lot of spambots.

This has been very effective and has had zero false positives from the
Internet. You may have issues with local, trusted email clients though,
but you can make exceptions for those hosts pretty easily.

I hope this helps,
M

--
Michael F. Sprague | mfs@saneinc.net
http://www.saneinc.net | use STD::disclaimer;
System and Network Engineering (SaNE), Inc
Re: (no subject) [ In reply to ]
On Wed, 5 Oct 2005, Michael Peek wrote:
>
> I would like to deny hosts whose $sender_helo_name/address doesn't match
> their $sender_host_name/address. The problem with this is that so many
> legitimate hosts aren't configured to tell me who they really are.

Yup.

> So my next brilliant idea was to accept HELO's that are "close" to each
> other, and I defined close as being if the first 3 out of 4 octets of
> their IP addresses are the same.

That won't work either, because many legitimate mail servers say HELO
using private names that are not valid outside their local networks, or
names which are resolvable publicly but which refer to RFC 1918 addresses
(e.g. eBay's mail servers).

> Before I go much farther with this (like dropping the required "closeness"
> from 24 bits to 16 bits -- all I really care about is that the remote host
> isn't obviously lying), what clever things have you guys implemented?

The only safe thing to do with HELO is to examine it for properties that
definitely indicate that the software at the other end is malware.
Misconfiguration does not imply malice! Our checks are slightly more
aggressive than those recommended by others on this list (particularly the
all-numeric check), but they seem to be pretty reliable.

deny
message = Please use your name when saying HELO (not $sender_helo_name)
condition = ${if or{{ eq{$ACL_HELO}{bad} } \
{ eq{$sender_helo_name}{$local_part} } \
{ match{$sender_helo_name}{^[0-9.-]+\$} } \
{ match{$sender_helo_name}{\N[.][.]|.{55}\N} } \
{ match_domain{$sender_helo_name}{+our_domains} }} }
set ACL_HELO = bad

Tony.
--
<fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
Re: (no subject) [ In reply to ]
Tony Finch wrote:
>
> The only safe thing to do with HELO is to examine it for properties that
> definitely indicate that the software at the other end is malware.
> Misconfiguration does not imply malice! Our checks are slightly more
> aggressive than those recommended by others on this list (particularly the
> all-numeric check), but they seem to be pretty reliable.
>
> deny
> message = Please use your name when saying HELO (not $sender_helo_name)
> condition = ${if or{{ eq{$ACL_HELO}{bad} } \
> { eq{$sender_helo_name}{$local_part} } \
> { match{$sender_helo_name}{^[0-9.-]+\$} } \
> { match{$sender_helo_name}{\N[.][.]|.{55}\N} } \
> { match_domain{$sender_helo_name}{+our_domains} }} }
> set ACL_HELO = bad

What's ACL_HELO used for? It is to short-circuiting the string
comparisons for subsequent RCPT's on the same connection?

- Marc
Re: (no subject) [ In reply to ]
On Thu, 6 Oct 2005, Marc Sherman wrote:
>
> What's ACL_HELO used for? It is to short-circuiting the string comparisons for
> subsequent RCPT's on the same connection?

There's a kind of spam software which sends messages with multiple
recipients, and which says HELO using the local part of the first email
address. My configuration uses an ACL variable to remember this so that
subsequent recipients are also rejected. e.g.

220 go on
HELO fanf2
250 yeah right
MAIL FROM:<spammer>
250 make my day
RCPT TO:<fanf2@cam.ac.uk>
550 go away
RCPT TO:<ph10@cam.ac.uk>
550-hah! can't fool me that easily!
550 I remembered that the previous recipient matched your helo name!
...

Tony.
--
<fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
Re: (no subject) [ In reply to ]
On Wed, 05 Oct 2005 14:56:43 -0400, Michael Sprague <mfs@saneinc.net>
wrote:
>If the HELO/EHLO cannot be verified, we do a delay of 20 secs in the
>connect and helo phases.

How can you delay on unverified HELO at connect time, when the remote
site has not yet issued its HELO phrase?

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: (no subject) [ In reply to ]
Marc Haber wrote:
> On Wed, 05 Oct 2005 14:56:43 -0400, Michael Sprague <mfs@saneinc.net>
> wrote:
>
>>If the HELO/EHLO cannot be verified, we do a delay of 20 secs in the
>>connect and helo phases.
>
>
> How can you delay on unverified HELO at connect time, when the remote
> site has not yet issued its HELO phrase?

My mistake. We delay in HELO phase only for an unverifiable HELO/EHLO.
We delay in the connect phase if the rDNS is unverifiable. :)

M

--
Michael F. Sprague | mfs@saneinc.net
http://www.saneinc.net | use STD::disclaimer;
System and Network Engineering (SaNE), Inc
Re: (no subject) [ In reply to ]
Tony Finch wrote:

> HELO fanf2
...
> RCPT TO:<fanf2@cam.ac.uk>
> 550 go away

So if I'd send a message to ymmv.de@dotat.at it would be rejected? As
you said, that's a little agressive.
My example is not that unlikely. I often use some.domain@plonk.de for
web registration forms, so I know who sold my address (not that it would
help much) and for filtering.
If you don't such things, your ACL is nice, of course.
Re: (no subject) [ In reply to ]
On Fri, 7 Oct 2005, Jakob Hirsch wrote:
>
> So if I'd send a message to ymmv.de@dotat.at it would be rejected?

Yes, because that's an invalid recipient.

> As you said, that's a little agressive.

No, it is a very reliable check.

Tony.
--
<fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
Re: (no subject) [ In reply to ]
--On 7 October 2005 11:45:39 +0100 Tony Finch <dot@dotat.at> wrote:

> On Fri, 7 Oct 2005, Jakob Hirsch wrote:
>>
>> So if I'd send a message to ymmv.de@dotat.at it would be rejected?
>
> Yes, because that's an invalid recipient.
>
>> As you said, that's a little agressive.
>
> No, it is a very reliable check.

It will be perfect as long as you don't allow your local parts to match
FQDNs. If they don't have dots in, you should be fine. Even if you do allow
them to match, the false positives will be low as long as nobody on your
system uses Jacob's technique of deliberately using foreign domain names as
local parts.

I used to use a similar system - using ian-example.com@... when registering
for a service at example.com. I've given up doing that now, because I keep
forgetting what name I've registered with, and because the amount of spam I
get to such addresses is vanishingly small (except for ian-php@... which is
still out there unmasked on some ancient mirrors of the php documentation
site).

> Tony.



--
Ian Eiloart
Servers Team
Sussex University ITS
Re: (no subject) [ In reply to ]
From: "Chris Jensen" <cjensen@gmail.com>
>
> I can't figure out how to successfully identify internal sender IP's
> from within a filter, I was hoping for something along the lines of
>
> # Set n1 to 1 if this is a local message
> if ${match_address{$sender_host_address}{$relay_from_hosts}} is 1
> then
> add 1 to n1
> endif

match_address is an expansion conditional, it needs to be used inside of
an *expansion* if statement, not a *filter* if statement.

Do something like this instead:

if ${if
match_address{$sender_host_address}{$relay_from_hosts}{true}{false}} is
true
then
add 1 to n1
endif

or you could just

add ${if match_address{$sender_host_address}{$relay_from_hosts}{1}{0}} to
n1

You need to remember that you are dealing basically with two different
languages here, the string expansion language and the filter language.
You can't arbitrarily mix and match, you need to keep each within its own
context.

David


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Re: (no subject) [ In reply to ]
B. Cook wrote:

> Hello all,
>
> I am installing a new server and doing something I've got happening on
> three other servers without a problem..
>
> I put exim on the outside of a qmail/vpopmail install, and exim only does
> smtp auth for ips not allowed to relay.
>
> It has a localhost router designed to send to qmail at 127.0.0.1:8125
>
> I setup a test.domain domain, and a bcook account in vpopmail, and I get
> back a strange message from exim when I try and send a test message.

Looks as if you have triggered the 'political correctness' routine of Exim's AI
engine.

When placed in a sufficiently weird environment, Exim has the ability to act
just the same as the other players so as not to attract undue attention to itself.

Basic survival mechanism, that is.

Reduce the surrounding weirdness and it will stop acting like that.

;-)

Bill


>
>
> Considering: bcook@test.domain
> unique = bcook@test.domain
> dbfn_read: key=R:test.domain
> dbfn_read: key=R:bcook@test.domain
> no address retry record
> bcook@test.domain: queued for routing
>
> routing bcook@test.domain
> --------> localhost router <--------
> local_part=bcook domain=test.domain
> calling localhost router
> localhost router called for bcook@test.domain
> domain = test.domain
> route_item = +localqmail 127.0.0.1
> search_open: lsearch "/var/qmail/control/rcpthosts"
> search_find: file="/var/qmail/control/rcpthosts"
> key="test.domain" partial=-1 affix=NULL starflags=0
> LRU list:
> :/var/qmail/control/rcpthosts
> End
> internal_search_find: file="/var/qmail/control/rcpthosts"
> type=lsearch key="test.domain"
> file lookup required for test.domain
> in /var/qmail/control/rcpthosts
> lookup yielded:
> test.domain in "lsearch;/var/qmail/control/rcpthosts"? yes (matched
> "lsearch;/var/qmail/control/rcpthosts")
> test.domain in "+localqmail"? yes (matched "+localqmail")
> original list of hosts = "127.0.0.1" options =
> expanded list of hosts = "127.0.0.1" options =
> set transport bsd_smtp
> finding IP address for 127.0.0.1
> calling host_find_byname
> local host found for non-MX address
> fully qualified name = 127.0.0.1
> gethostbyname looked up these IP addresses:
> name=127.0.0.1 address=127.0.0.1
> LOG: MAIN
> remote host address is the local host: test.domain
> localhost router: defer for bcook@test.domain
> message: remote host address is the local host
> added retry item for R:test.domain: errno=-1 more_errno=0 flags=0
> post-process bcook@test.domain (1)
> LOG: MAIN
> == bcook@test.domain R=localhost defer (-1): remote host address is the
> local host
>
>
>
> and the routers section from my configure file:
>
> begin routers
>
> localhost:
> transport = bsd_smtp
> driver = manualroute
> route_list = +localqmail 127.0.0.1
>
> manual:
> transport = remote_smtp
> driver = dnslookup
> domains = +manual_domains
>
> smarthost:
> transport = remote_smtp
> driver = manualroute
> route_list = !+manual_domains 1.2.3.4
> no_more
>
> begin transports
>
> remote_smtp:
> driver = smtp
>
> bsd_smtp:
> driver = smtp
> port = 8125
>
>
> and qmail is running..
> # telnet localhost 8125
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 qmail.test.domain ESMTP
>
> And I have working internal dns..
>
> [root@pcsdmail /usr/local/etc/exim]# cat /etc/resolv.conf
> search at.home
> nameserver 172.16.64.1
> [root@pcsdmail /usr/local/etc/exim]# host 127.0.0.1
> 1.0.0.127.in-addr.arpa domain name pointer localhost.
> [root@pcsdmail /usr/local/etc/exim]# host localhost
> localhost.at.home has address 127.0.0.1
>
>
> This is the part that I am confused about in the debug session:
>
> set transport bsd_smtp
> finding IP address for 127.0.0.1
> calling host_find_byname
> local host found for non-MX address
> fully qualified name = 127.0.0.1
> gethostbyname looked up these IP addresses:
> name=127.0.0.1 address=127.0.0.1
>
> I'm confused why it's doing gethostbyname, and why if it's wrong.. why it
> works on the other boxes?
>
>
>


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Re: (no subject) [ In reply to ]
On Saturday 07 October 2006 23:50, B. Cook took the opportunity to say:
> I put exim on the outside of a qmail/vpopmail install, and exim only does
> smtp auth for ips not allowed to relay.
>
> It has a localhost router designed to send to qmail at 127.0.0.1:8125
>
> begin routers
>
> localhost:
> transport = bsd_smtp
> driver = manualroute
> route_list = +localqmail 127.0.0.1

You can set the port in the router instead:

transport = remote_smtp
route_list = +localqmail 127.0.0.1::8125

You also have to use

self = send

to convince Exim that it's not going to be talking to itself.

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
Re: (no subject) [ In reply to ]
On Sat, October 7, 2006 6:41 pm, Magnus Holmgren wrote:
> On Saturday 07 October 2006 23:50, B. Cook took the opportunity to say:
>> I put exim on the outside of a qmail/vpopmail install, and exim only
>> does
>> smtp auth for ips not allowed to relay.
>>
>> It has a localhost router designed to send to qmail at 127.0.0.1:8125
>>
>> begin routers
>>
>> localhost:
>> transport = bsd_smtp
>> driver = manualroute
>> route_list = +localqmail 127.0.0.1
>
> You can set the port in the router instead:
>
> transport = remote_smtp
> route_list = +localqmail 127.0.0.1::8125
>
> You also have to use
>
> self = send
>
> to convince Exim that it's not going to be talking to itself.

localhost:
#transport = bsd_smtp
transport = remote_smtp
driver = manualroute
route_list = +localqmail 127.0.0.1::8125
self = send

works great ;)

And with that.. I was able to figure out why the others work and this one
didn't..

SELF = 172.16.64.6 : 127.0.0.1
local_interfaces = SELF

All the other boxes have SELF defined as the local ip and *not* the
loopback..

So my bug/problem was that exim already saw that 127.0.0.1 was 'exim' and
never checked to see if it was anything else b/c it was listening on it..
even though I was telling it to go to a different port.

Thank you ;)


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Re: (no subject) [ In reply to ]
On Thursday 03 May 2007 11:08, rohit sakalle wrote:
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> I am trying implemented one local_scan function. Now if I just pass all
> the required options to dccifd deamon processs.....
> So how it will find the DCC server I just know the port of the dccifd
> daemon. Is it true that daemon process automatically will find the
> Distributed&nbsp; Checksum Clarinhouse&nbsp; server. Or I need to do coding
> for that. If possilbe tell me also how daemon process find this DCC server.

Sorry, but this is well outside the scope of this mailing list. Try a more
DCC-oriented one.

--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)

"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
Re: (no subject) [ In reply to ]
On 23/01/2019 16:43, Rob Gunther via Exim-users wrote:
> Am I correct in assuming Exim is tracking the server status by the
> destination server name? Just ASPMX.L.GOOGLE.COM. If we are getting those
> 421 errors back, Exim pauses delivery attempts for a while.
>
> Exim does not seem to track the domain/destination server as the
> combination for tracking server outages or issues etc.

http://exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html

Per-host retries are distinguished from per-message retries.
Sounds like you get the former.

>
> Is there any way to have it not retry for Customer 1, but Customer 2 would
> have its own status retained by Exim... so customer 1 can't impact customer
> 2 delivery speed.

also see the address_retry_include_sender on the smtp transport.

--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: (no subject) [ In reply to ]
On Thu, 24 Jan 2019, Rob Gunther via Exim-users wrote:

> We are accepting mail for customer domains, then delivering the mail using
> Exim to the customer server. Customer servers can be anywhere, as long as
> it answers to SMTP requests.
>
> Come across a problem, two users hosted by Google.
>
> Customer 1 has somehow added IP restrictions in the Google platform to only
> accept mail from specific IP addresses. He has messed up and not added one
> of our IP addresses to the list, so google rejects the message deliveries
> with:
>
> 421 4.7.0 IP not in whitelist for RCPT domain, closing connection.
>
> We have Exim put the message back into the delivery queue for a retry later.

Do the retried messages ever succeed ?
If the problem is that Google is not accepting from *one* of your IP
addresses, I am surprised if the retries ever succeed for that customer.

If this is indeed the problem, it would be better to have an exim router
*on that host* that passes customer1's messages to another of your hosts,
which can then pass the message to google without problems.
(I am conflating "host" with sending IP address here).

--
Andrew C. Aitchison Cambridge, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

1 2  View All