> any body out there pliz help.
The path is /var/db/mysql and not /var/db/msql.
> $sender_helo_name/address doesn't match their $sender_host_name/address.
> Before I go much farther with this (like dropping the required "closeness"
> isn't obviously lying), what clever things have you guys implemented?
> being broken up and deregulated and all.
> the remote sender's hostname/address in some way?
> Maybe I should just chuck it out the window?
cases where it is useful. But I would recommend keeping it simple.
connect and helo phases. These delays catch a lot of spambots.
but you can make exceptions for those hosts pretty easily.
> legitimate hosts aren't configured to tell me who they really are.
> their IP addresses are the same.
definitely indicate that the software at the other end is malware.
all-numeric check), but they seem to be pretty reliable.
> definitely indicate that the software at the other end is malware.
> all-numeric check), but they seem to be pretty reliable.
comparisons for subsequent RCPT's on the same connection?
> subsequent RCPT's on the same connection?
subsequent recipients are also rejected. e.g.
550-hah! can't fool me that easily!
550 I remembered that the previous recipient matched your helo name!
site has not yet issued its HELO phrase?
> site has not yet issued its HELO phrase?
My mistake. We delay in HELO phase only for an unverifiable HELO/EHLO.
you said, that's a little agressive.
help much) and for filtering.
If you don't such things, your ACL is nice, of course.
> 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.
>> 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.
an *expansion* if statement, not a *filter* if statement.
languages here, the string expansion language and the filter language.
> three other servers without a problem..
> smtp auth for ips not allowed to relay.
> back a strange message from exim when I try and send a test message.
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.
> and qmail is running..
> And I have working internal dns..
> 1.0.0.127.in-addr.arpa domain name pointer localhost.
> works on the other boxes?
to convince Exim that it's not going to be talking to itself.
>> smtp auth for ips not allowed to relay.
> to convince Exim that it's not going to be talking to itself.
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.
> for that. If possilbe tell me also how daemon process find this DCC server.
> 421 errors back, Exim pauses delivery attempts for a while.
> combination for tracking server outages or issues etc.
Per-host retries are distinguished from per-message retries.
Sounds like you get the former.
also see the address_retry_include_sender on the smtp transport.
> it answers to SMTP requests.
> Come across a problem, two users hosted by Google.
> 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 ?
addresses, I am surprised if the retries ever succeed for that customer.
which can then pass the message to google without problems.
(I am conflating "host" with sending IP address here).