| Author |
Message |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
spam control and HELO
|
|
|
RM> however, I've never received one with *my* IP address in the HELO
string - it's all been spam.
Ironically, this is the one case where this "anti-UBM" measure has
justification. Rejecting a "EHLO"/"HELO" that uses the SMTP Relay
server's _own_ identity is exactly what an SMTP Relay server is
_supposed_ to do. The parameter to "EHLO"/"HELO" is a loop detection
mechanism, as originally designed. It's an *obsolete* loop detection
mechanism, that became obsolete even before SMTP saw widespread use.
But its use as originally designed is still legitimate. So one can
happily reject all SMTP Relay clients trying to send UBM that think that
they are being smart (but are in fact being dumb) by claiming the
server's own identity. (MUAs that are mis-using SMTP Relay for SMTP
Submission are an issue here, since some popular MUAs will end up using
the server's own identity too. But such applications should be
reconfigured to use SMTP Submission, and - since the verbs have far less
use in SMTP Submission - not use "EHLO"/"HELO" at all.) |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
"Let's hammer the spammers!", take #17.
|
|
|
RM> It would be better to put more energy into:
RM>
RM> http://www.im2000.org/
RM>
RM> Laterz, Roger "Merch" Merchberger
X> Lycos is doing such a thing, [...]
X> It is however not the way to go. And should not be done. [...]
X> the lycos site was hacked already [...]
More accurate rumour has is that access to the Lycos site was blocked by
ordinary network operators, for the same reasons that they block access
to other people who execute distributed denial of service attacks via
vast networks of remote-controlled processes on other people's machines. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
"Let's hammer the spammers!", take #17.
|
|
|
JF> I just wish that the legal system was not so full of crap.
Sturgeon's Law.
JF> P.s can't this list server set the reply-to headers?
<URL:http://unicom.com./pw/reply-to-harmful.html>
Set them yourself. It's you that is supposed to set them. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: qmail treating remote as local
|
|
|
A> My qmail will attempt to deliver it locally [...] and fails [...]
False.
A> qr> <root@strugglers.net>:
A> qr> Sorry. Although I'm listed as a best-preference MX or
A> qr> A for that host, it isn't in my control/locals file, so
A> qr> I don't treat it as local. (#5.4.6)
"qmail" is trying to delivery the mail *remotely*, not locally; but
"qmail-remote" has noticed a loop, and pointed out the usual cause for
such loops. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: dynamic ip rejected
|
|
|
P> I am getting the following error in my logs what does that mean?
It means that the SMTP Relay server at 163.200.216.139 has assigned
third class Internet citizen status to your IP address 216.252.155.2.
Such servers only deign to talk to first class or second class Internet
citizens. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Challenge Response
|
|
|
OC> Is anyone out there running any type of challenge response?
Yes. Alan Connor claims to be, for one.
<URL:http://angel.1jh.com./nanae/kooks/alanconnor.shtml> |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Relay rejected with 553 error
|
|
|
AI> When I try to send an email from this Solaris box using my qmail
AI> server [...]
You end up instead sending it via Sendmail:
AI> Return-Path: <iqbala>
AI> Received: (from iqbala@localhost) by
AI> cricket.qwest.com (8.11.7p1+Sun/8.11.7) id iB9MNDm29438;
AI> Thu, 9 Dec 2004 17:23:13 -0500 (EST)
AI> Date: Thu, 9 Dec 2004 17:23:13 -0500 (EST)
If you want help with a "qmail" problem, try actually using "qmail" in
the first place. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Is it qmail load, named killed
|
|
|
BG> I am noticing from a couple of days sometimes automatically named
BG> getting killed and thus I am getting delay in browsing the internet.
The subject of ISC's BIND dying at intervals is a perennial one in the
discussion forum for ISC's BIND. And it has _nothing whatever_ to do
with "qmail". Either join the ranks of those posting about BIND
crashing on them (and receive the same "step onto the perpetual upgrade
treadmill" responses as they do), or, as Bob suggested, replace ISC's
BIND with another DNS server software entirely.
<URL:news://news.gmane.org./cmqq66$m7p$1@sf1.isc.org> |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Extra Carriage Return In Header
|
|
|
RJ> You mayme can patch blast() in qmail-smtpd.c to accept a carriage
RJ> return after a "From:" only, if there was a "@" between. (no realy
RJ> clean solution).
Or he can arrange for mail coming from his LookOut box to pass through
"ofmipd" instead of "qmail-smtpd", an equally poor solution. Or he can
fix the MUA that cannot display "From:" headers properly, a far better
solution. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Little patch for setting the From:
|
|
|
BL> Why everybody is not with ipv6? ;)
Don't think that if IP version 6 were ubiquitous that people would no
longer use NAT. For better or for worse, they still would. And don't
think that if IP version 6 were ubiquitous your notion would become a
good one. It wouldn't. Sender mailbox names do not correlate to client
IP addresses *especially* when they are IP version 6 addresses.
(Consider autoconfiguration and the case of the user who swaps a NIC in
his/her PC, for starters.) |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: qsecretary notice
|
|
|
JG> Ok, I have subscribed to this list already, [...]
<sigh> Always stick the word "qsecretary" into Google Web *before* posting.
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/djb-qsecretary.html> |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Strange 'Return-Path: #@[]' for double bounces
|
|
|
EW> But this message got a strange 'Return-Path: <#@[]>'. With this value
EW> I can't POP this messages and feed them to my local MTA (via
EW> 'fetchmail') because the MTA rejected the mails with this
EW> 'Return-Path'.
Good. Use "getmail" and stop trying to re-inject messages that have
already been delivered to a mailbox, merely so that you can transfer
them to another mailbox.
<URL:http://qcc.ca./~charlesc/software/*getmail*-4/>
EW> So how do I get off this strange return-path?
Stop using that chocolate-covered banana.
<URL:http://perl.plover.com./Questions3.html> |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: possible spam w/ Delivered-To line?
|
|
|
OH> 2004-10-06 05:59:07.511245500 98261 > 220 mail.olabinc.com ESMTP
OH> 2004-10-06 05:59:07.936454500 98261 < HELO ISA-1
OH> 2004-10-06 05:59:07.936718500 98261 > 250 mail.olabinc.com
OH> 2004-10-06 05:59:08.373192500 98261 < MAIL FROM:<dajrwmh@mayaonline.com>
OH> 2004-10-06 05:59:08.373496500 98261 > 250 ok
OH> 2004-10-06 05:59:08.767477500 98261 < RCPT TO: <curtis@olabinc.com>
OH> 2004-10-06 05:59:08.767692500 98261 > 250 ok
OH> 2004-10-06 05:59:09.179198500 98261 < DATA 2004-10-06 05:59:09.180364500 98261 > 354 go ahead
OH> 2004-10-06 05:59:09.575875500 98261 < Return-Path: <KVBHHNQTQFVADIQSEPEUOPXK@northlandmortgage.com>
OH> 2004-10-06 05:59:09.717241500 98261 < Delivered-To: curtis@olabinc.com
CC> If this message bounces for any reason (including your concerns about Delivered-To:),
CC> qmail will deliver the bounce message to <dajrwmh@mayaonline.com>.
And thus the UBM sender at 211.250.81.252 has persuaded Otto's system to
deliver a bounce message, containing the original payload, to
<dajrwmh@mayaonline.com>. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Does netqmail-1.05 have the big-dns patch in it?
|
|
|
KW> Netqmail-1.05 does not include the big-dns patch. This is for
KW> several reasons, one of which is that if you use qmail with a
KW> local djbdns resolver, djbdns handles the problem for you.
"djbdns" *masks* the problem (It does not handle it.) and only
imperfectly at that.
<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/28942/fid/284>
PJ> So, do I need to apply the big-dns patch to my netqmail install?
KW> Need? No, [...]
The correct answer, if he is encountering the lookup problems, is "Yes.".
I cannot confirm, having not read it to check that it too removes the
512 byte response size limitation, that Nikola Vladov's patch also fixes
the problem. |
|
| Back to top |
|
 |
Jonathan de Boyne Pollard *nix forums beginner
Joined: 07 Jan 2005
Posts: 49
|
Posted: Fri Jan 07, 2005 6:51 pm Post subject:
Re: Qmail and SSL
|
|
|
E> No changes to the run file are needed if you use Frederik Vermeulen's
E> TLS patch: http://inoa.net/qmail-tls/netqmail-1.05-tls-20040419.patch
That patch is not the right way to go if SMTP/SSL is what one wants, as
is the case here. (Note that TLS and SSL are not the same thing.) It's
not necessary to be intrusive into the code of the service program, as
that patch is (and highly so), _at all_ in order to provide an SSL/TCP
service. The layering of the server end of a TCP service over SSL is
quite clean. The modular approach of "sslserver", which requires no
modification to stock "{net,}qmail", is by far the better one. |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|