ImapD connecting from localhost???
To add more info to the problem, im also getting errors at the same time
with my qpopper
as below..
May 7 12:29:38 sleepy in.qpopper[8370]: connect from 127.0.0.1
May 7 12:29:38 sleepy in.qpopper[8370]: (null) at sleepy (127.0.0.1):
-ERR POP EOF or I/O Error [popper.c:794]
May 7 12:29:38 sleepy in.qpopper[8370]: I/O error flushing output to
client at sleepy [127.0.0.1]: Operation not permitted (1)
[pop_send.c:685]
May 7 12:29:38 sleepy in.qpopper[8370]: I/O error flushing output to
client at sleepy [127.0.0.1]: Operation not permitted (1)
[pop_send.c:685]
May 7 12:29:38 sleepy imapd[8371]: connect from 127.0.0.1
May 7 12:29:38 sleepy imapd[8371]: imap service init from 127.0.0.1
May 7 12:29:38 sleepy imapd[8371]: Connection reset by peer, while
reading line user=??? host=UNKNOWN
-----Original Message-----
From: Mario Zuppini [mailto:tribune@cybersol.com.au]
Sent: Tuesday, 7 May 2002 11:02 AM
To: debian-isp@lists.debian.org
Subject: ImapD connecting from localhost???
Hi,
For months now my ImapD has been working flawlessly and it has only
recently come to my attention of the following error in my log
files..Can anyone shed some light on why it is connecting from localhost
and how/if can to fix it ??
May 7 10:49:39 sleepy imapd[18831]: connect from 127.0.0.1
May 7 10:49:39 sleepy imapd[18831]: port 220 service init from
127.0.0.1 May 7 10:49:39 sleepy imapd[18831]: Connection reset by peer,
while reading line user=??? host=UNKNOWN
Mario..
-----Original Message-----
From: Jason Lim [mailto:maillist@jasonlim.com]
Sent: Tuesday, 7 May 2002 10:18 AM
To: Marc Haber; debian-isp@lists.debian.org
Subject: Re: [Fwd: Re: Spamassasin over RBL, was Re: rblsmtpd -t?]
>And Spamcop does *NOT* block entire ranges of IPs like other RBLs, so
>it is virtually impossible for you to say that t-online, gmx and web.de
>are "blocked". Only the spamming IPs within their ranges would be
>blocked,
NOT
>the entire range.
>T-Online does Port 25 blocking, forcing you to use their smarthost. GMX
>and web.de are e-mail only services and offer SMTP-AUTH-based e-mail
>services. If their smarthost gets blocked, I dare to say that T-Online
>is blocked. I couldn't receive _any_ e-mail from _any_ T-Online user
>for a week, which virtually means shutting me off from Germany's
>largest-by-far end-user ISP.
In that case, T-Online will not have a problem, as the user's IP will be
blocked, not the mail server, UNLESS T-Online has setup their mail
server to hide their user's IP, which most ISPs do not do.
On the other hand, it would be weird if GMX and web.de only have 1
outgoing mail server. I assume that they, like hotmail and other
freemail services, would have many multiple outgoing mail servers to
handle their traffic (just for example, mail12.web.de, mail6.web.de,
etc.). Then only one of the mail servers, at most, would be blocked.
And anyway, spam really shouldn't be able to come out of web-based email
services. Don't they have rate-limiting or anything like that
implemented? I know that even with Hotmail's service, if you set it up
on Outlook Express to bypass their web-based login, that your IP *does*
should up in the email sent. Your IP does not should up if you login via
the web, but then, you cannot send many emails. So there is a
trade-off... so web-based email providers would all probably be smart
enough to implement a similar system, right?
>Then, if GMX and these other ISPs kick out that spammer, after 1 week
that
>IP is again clear, so it can again send email.
>Great. After two hours, I'd have customers complaining.
True, but I was assuming that these companies have more than one IP, and
more than one mail server.
And as I said, a dialup/broadband ISP will not have a problem, as the
block IP will be that of their customer, not of their mail server.
A web-based freemail provider will also not have a problem, as they
*should* implement rate-limiting on their outgoing mail (to stop people
sendng 1,000 emails/day from their account, and other silly things like
that).
Now, if gmx and web.de allow people to send unlimited emails from their
account, and other stupid things like that, then perhaps they will be
blocked. But would they be that stupid?
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: