headers
John Simpson | 2 Nov 2008 01:50
Favicon

Re: Qmail Log Tutorials


On 2008-10-31, at 0940, Wesley Simpson wrote:
>
> John,
>
> I've downloaded mtrack & strack from your site, and apparently they do
> not recognize the format of my client's qmail log.

your client isn't running qmail. they're running plesk.

>  My client is
> extremely apprehensive about any changes I might want to make to the
> system (because "I break things" ...).  I have looked at the  
> contents of
> the script files and find the code to be extremely cryptic to me, perl
> being one of the languages I have not yet tackled.  I am hoping that  
> you
> might be able to recognize the discrepancy here and provide either a
> quick fix, or advice on what might be a better route for me to go.

plesk does some really crazy things with its bastardized version of  
what used to be qmail. this includes the format of its log files.

if your client is willing to pay for my time, i'm willing to try and  
customize "mtrack" to read their log files. however, looking at the  
sample included with your message, it may end up dropping some  
information, because it looks like there isn't enough information in  
some of the log entries to properly correlate with other log entries.  
contact me off-list if so.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Heidi Grab | 2 Nov 2008 09:25

qmail, spams and mailer-daemon

Hi there,

I have app. 4000-5000 incoming spam e-mails daily. 83 percent of it is  
recognized as spam by spamassassin and 0 percent of ham. (If we get  
tighter on spamassassin, there is ham also getting caught, so we  
decided to leave it as it is for now.)

Over 60 users have set up their e-mail accounts so that they get their  
e-mails forwarded.

Until recently we did not interfere with their e-mails. We marked them  
as probable spam, but continued to deliver them.

However, since the number of spam mails is constantly on the rise, we  
decided to block spam messages with a 5.7.0 error message (Your e-mail  
is probable spam. Please write to .... if we are wrong.)

Well, as you can imagine, this did not decrease the load on the mail  
server. The mails do not get delivered to their original recipients,  
but the 5.7.0 mailer-daemon message tries to get through - and almost  
always in vain, because either the return adress is a fake and doesn't  
exist or the e-mail adress is a fake and the recipient doesn't even  
know that some spam bot used his e-mail adress to fake messages.

Any way, those 5.7.0 messages seem to be completely useless, because  
they never reach the sender anyway.

What do you think about delivering spam messages to /dev/null? And how  
could we adjust the dotqmail files to do this?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Oliver Welter | 2 Nov 2008 10:46
Picon
Gravatar

Re: qmail, spams and mailer-daemon


Hi Heidi,

> However, since the number of spam mails is constantly on the rise, we
> decided to block spam messages with a 5.7.0 error message (Your e-mail
> is probable spam. Please write to .... if we are wrong.)
> 
> Well, as you can imagine, this did not decrease the load on the mail
> server. The mails do not get delivered to their original recipients, but
> the 5.7.0 mailer-daemon message tries to get through - and almost always
> in vain, because either the return adress is a fake and doesn't exist or
> the e-mail adress is a fake and the recipient doesn't even know that
> some spam bot used his e-mail adress to fake messages.
> 
> Any way, those 5.7.0 messages seem to be completely useless, because
> they never reach the sender anyway.
> 
> What do you think about delivering spam messages to /dev/null? And how
> could we adjust the dotqmail files to do this?

NO Dont do this! Its against RFCs and will make your users angry if you
drop legal messages silently.

The better approach is, to reject the Spams at SMTP Level. This is
independant of any forged Envelopes and leaves the creation of a "Non
Delivery Report" to the contacting MTA. In most cases this will be a
spammer who is not interessted in NDRs, but thats not your business.

A second option might be greylisintg - I know there is an ongoing
disussion about the usage of greylisting but at least for me, it figures
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Wesley Simpson | 2 Nov 2008 15:37

Re: Qmail Log Tutorials


On Sat, 2008-11-01 at 20:50 -0400, John Simpson wrote:

> On 2008-10-31, at 0940, Wesley Simpson wrote:
> >
> > John,
> >
> > I've downloaded mtrack & strack from your site, and apparently they do
> > not recognize the format of my client's qmail log.
> 
> ... your client isn't running qmail. they're running plesk. ... looking at the  
> sample included with your message, it may end up dropping some  
> information, because it looks like there isn't enough information in  
> some of the log entries to properly correlate with other log entries. 

> > Should I be looking instead at djb's daemontools or multilog instead?
> 
> if you don't mind breaking plesk, sure.

John,

Thank you for getting back to me.  PLESK has definitely been
entertaining to work with.  I'll let you know offline if my client wants
to pursue this.

--

-- 
John Wesley Simpson <john <at> swajime.com>
SwaJime's Cove
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Simpson | 2 Nov 2008 21:26
Favicon

Re: qmail, spams and mailer-daemon


On 2008-11-02, at 0325, Heidi Grab wrote:
>
> What do you think about delivering spam messages to /dev/null? And  
> how could we adjust the dotqmail files to do this?

first, make sure that you KNOW the messages are spam. if you're not  
100% sure, it's safer (in terms of not losing legitimate messages) to  
just pass it through to the intended recipient, and let them deal with  
the effort of hitting the DELETE key.

and even if you are 100% sure- if the sending IP is a known spammer,  
for example- then your best bet is to simply refuse to accept the  
message during the SMTP transaction. that way if it IS a legitimate  
message, the machine which tried to hand it to you will try again, or  
it will generate a bounce message. and if the sender is a spammer,  
they will not have succeeded in making your machine deal with the  
message to begin with.

if you really feel the need to accept the message and then drop it,  
create the appropriate ".qmail" file with "#" as the only line. qmail- 
local will see that the .qmail file exists, and isn't empty, so it  
will use it. and if the file contains no real delivery instructions,  
the message won't ever really be delivered anywhere, but qmail-local  
will tell qmail-send that the message was successfully delivered, and  
qmail-send will remove it from the queue like it would any  
successfully delivered message.

another problem with this approach is that the spammer will only know  
that your server accepted the message, so they will continue to send
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Hutchinson | 3 Nov 2008 00:29
Picon

RE: netqmail-1.06 and DNS patch

> -----Original Message-----
> From: Vahid Moghaddasi [mailto:vahid.moghaddasi <at> gmail.com]
> Sent: 24 October 2008 4:23 a.m.
> To: qmail <at> list.cr.yp.to
> Subject: netqmail-1.06 and DNS patch
> 
> Hi all,
> After so many years of faithful delivery, we have just noticed that
> all the mails to *.ibm.com fails with
> CNAME_lookup_failed_temporarily._(#4.4.3)/ and after queuelifetime it
> bounces back to user.
> 
> I upgraded a few servers from netqmail-1.05 to 1.06 which I assume has
> the DNS patch already in it but I still see the following errors.
> 
> 2008-10-23 10:51:33.529146500 starting delivery 41344: msg 39032 to
> remote someuser <at> us.ibm.com
> 2008-10-23 10:51:53.540680500 delivery 41344: deferral:
> CNAME_lookup_failed_temporarily._(#4.4.3)/
> .....
> 2008-10-23 10:51:58.549636500 starting delivery 41345: msg 38922 to
> remote someuser <at> in.ibm.com
> 2008-10-23 10:52:18.561078500 delivery 41345: deferral:
> CNAME_lookup_failed_temporarily._(#4.4.3)/
> 
> Do I need to apply the patches (DNS and other) or it is already
> applied with 1.06?
> 
> Thank you,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Richards | 3 Nov 2008 10:44
Picon
Favicon

Announce: qmail-errmsg v1.1 - qmail-smtpd error logging for netqmail

Hi,

Further to the comments received on the qmail-errmsg patch I released 
2 weeks ago I've updated the patch - thank you to all those who 
contributed ideas and suggestions - find the updated version here:

  http://free.acrconsulting.co.uk/email/qmail-errmsg.html

Here is a sample of the output it provides (annotated, timestamps 
converted),

http://free.acrconsulting.co.uk/sw/patches/netqmail-errmsg-v1.1.sample.log

cheers,

Andrew Richards.
--

-- 
======================================================================
   * Custom email solutions * Systems Administration * Networking
		http://www.acrconsulting.co.uk/
====================================================================
Permalink | Reply | 1 comment |
headers
Andrew Richards | 3 Nov 2008 10:50
Picon
Favicon

Re: Announce: qmail-errmsg - qmail-smtpd error logging for netqmail

On Tuesday 21 October 2008 09:47, Erwin Hoffmann wrote:
> Hi,
>
> so re-invent the wheel ?
>
> As ist has been discussed in this thread, the log-format is crucial
> for a later analysis.
>
> Consider to parse 10 GB of qmail-smtpd logs per day (which is not
> untypical for a busy server).
>
> Check out SPAMCONTROL's log format:
>
> http://www.fehcom.de/qmail/spamcontrol/README_spamcontrol.html
> (chapter 9).

I've taken a look at this; for the benefit of the list here's the 
example log line you provide,

Accept::SNDR::Relay_Client: P:orion.fehnet.de 
S:81.173.229.48:xdsl-81-173-229-48.netcologne.de H:mail.fehcom.de 
F:feh <at> fehcom.de T:erwin <at> example.com

but that's not what I want: I'm keen to have a more human 
readable log message that can also be processed to pull out desired 
data; I also don't want to add too much code to qmail-smtpd.c - 
therefore I've updated the patch taking on board as much as I can of 
the comments received including yours; I'll start a new thread with 
the new patch. I've also added an example awk script to do some 
post-processing: This could be extended to provide terser output such
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erwin Hoffmann | 3 Nov 2008 12:35
Picon

Re: Announce: qmail-errmsg - qmail-smtpd error logging for netqmail

Hi,

--On 3. November 2008 09:50:00 +0000 Andrew Richards 
<ar-djblists <at> acrconsulting.co.uk> wrote:

> On Tuesday 21 October 2008 09:47, Erwin Hoffmann wrote:
>> Hi,
>>
>> so re-invent the wheel ?
>>
>> As ist has been discussed in this thread, the log-format is crucial
>> for a later analysis.
>>
>> Consider to parse 10 GB of qmail-smtpd logs per day (which is not
>> untypical for a busy server).
>>
>> Check out SPAMCONTROL's log format:
>>
>> http://www.fehcom.de/qmail/spamcontrol/README_spamcontrol.html
>> (chapter 9).
>
> I've taken a look at this; for the benefit of the list here's the
> example log line you provide,
>
> Accept::SNDR::Relay_Client: P:orion.fehnet.de
> S:81.173.229.48:xdsl-81-173-229-48.netcologne.de H:mail.fehcom.de
> F:feh <at> fehcom.de T:erwin <at> example.com
>
> but that's not what I want: I'm keen to have a more human
> readable log message that can also be processed to pull out desired
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle Wheeler | 3 Nov 2008 19:21

Re: qmail, spams and mailer-daemon


On Sunday, November  2 at 09:25 AM, quoth Heidi Grab:
> I have app. 4000-5000 incoming spam e-mails daily.

That's it? ;)

> 83 percent of it is recognized as spam by spamassassin and 0 percent 
> of ham. (If we get tighter on spamassassin, there is ham also 
> getting caught, so we decided to leave it as it is for now.)

That's pretty good, but 0 false positives is, at best, not perfectly 
sustainable. Spamassassin makes no guarantees, and so you shouldn't 
rely on it to give you guarantees, no matter how you have it 
configured. It's like the stock market: past returns are no guarantee 
of future performance.

> Over 60 users have set up their e-mail accounts so that they get 
> their e-mails forwarded.
>
> Until recently we did not interfere with their e-mails. We marked them as 
> probable spam, but continued to deliver them.

Which, given that that's exactly what they told you to do, would make 
sense.

> However, since the number of spam mails is constantly on the rise, 
> we decided to block spam messages with a 5.7.0 error message (Your 
> e-mail is probable spam. Please write to .... if we are wrong.)

PLEASE do not do that. The return address is almost *ALWAYS* fake, and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane