Re: what can be done about 'in order to have your advice...'
On Tue, Jul 24, 2001 at 10:58:10AM -0400, [EMAIL PROTECTED] wrote: > > Can anyone help me figure out a way to handle this recent virus? > > It typically tags email in body: >'...in order to have your advice...' > > and sends random attachments .2 to 2Mb in size. > > We're getting a lot of these already, and I'm worried > that a flood will jam us up, amounting to a DOS. At the very > least, this is going to cost us a lot of bandwidth $$$. > > Seems to me the only way to stop it is to scan the body before > the mail is accepted. Yeech. And as soon as we get variations on > '...in order to have your advice...' it will be just about > indistinguishable from normal email with attachments. If it helps, I process the header with ^Content-Type:.*_Outlook_Express_message_boundary virus W32/Sircam-A-Virus Now just find a place to put that (my implementation is not site-portable). And no, it won't block real Outlook Express mails. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: High Volume....
On Tue, Jul 03, 2001 at 09:11:33AM +0200, Peter van Dijk wrote: > On Mon, Jul 02, 2001 at 11:37:03AM +0200, Xavier Pegenaute wrote: > > Hi all.. > > > > i can try any prime number for hashing ..? ( is limited?) > > You can try any number, but anything over 1/1000th of your queuesize > is overkill. I thought it would be better to take a number about the square root of the top queue size, which minimizes search length on a classical file system. For 23000 your on the order of 151, which happens to look prime. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: Why conf-split prime?
On Thu, Jun 21, 2001 at 02:25:52PM -0400, Russell Nelson wrote: > > speed. However, why should this number be prime, why not have 12 or 16 > > directories? > > Because it's a hash. If your hash isn't prime, you fill your hash > buckets unevenly. I think we are spreading urban legends here. AFAIK, the primality is for double hashing in conflict resolution. Nothing of that kind is going on here. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: smtp auth failures
On Tue, Jun 19, 2001 at 09:38:37PM +, Nick (Keith) Fish wrote: > joc wrote: > > >There it is. any wise thoughts here? > > > > Thanks > > John > > Encourage your customers to use non-broken MUA. Our company refuses to > support anything other than Outlook Express, Netscape Messenger, and our > own web-based e-mailing service. You might try that: promoting a > web-based e-mail service they can access FROM ANYWHERE IN THE WORLD! That > always makes them giddy. :-) And which of these is the non-broken MUA? SCNR Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Bug? in qmail-inject: QMAILINJECT=f ruins resent mails
As old unix "MUA"s have the habit of providing a from line of "[EMAIL PROTECTED]" and, even with new MUAs, user can't be bothered to configure them correctly, we set up the following environment variables in /etc/profile and such: QMAILHOST QMAILUSER QMAILINJECT=f This usually works nicely for the vintage MUAs, and doesn't do anything bad with sensible MUAs like mutt or Gnus. But: If you are resending a message to someone else with a sensible MUA, it will add Resent-From: etc. headers. Then qmail-inject goes ahead and removes the original From: header (beacuse of QMAILINJECT=f) and looks if it must add a new Resent-From: header (it doesn't need to) and the mail is sent without any From: header at all. So: 1. If you are using a sensible client, be smart enough to unset QMAILINJECT. 2. qmail-inject could be enhanced by making the process of removing and adding headers more symmetrical. 3. It could be termed a bug because qmail-inject shouldn't produce a non-RFC 2?822 message, with no regard to the setting of QMAILINJECT. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: Where is tai64nfrac
On Thu, Apr 12, 2001 at 04:17:47PM +0100, [EMAIL PROTECTED] wrote:
> For instance at:
>
> http://sunsite.dk/qmail/tai64nfrac
>
> or
>
> http://qmail.sst.com.br/tai64nfrac
>
AFAIK, (this version) of tai64nfrac is broken, because
printf("%lu.%lu ", seconds, nanoseconds);
suppresses leading zeroes in the fractional part.
Jost
--
| [EMAIL PROTECTED] Please help stamp out spam! |
| Postmaster, JAPH, resident answer machine am RZ der RUB |
| Pluralitas non est ponenda sine necessitate |
| William of Ockham (1285-1347/49) |
Re: double bounce policy
On Sat, Sep 23, 2000 at 12:06:13AM +0300, Jos Okhuijsen wrote: > What is your policy for double bounces? > Users come and go, and always seem to leave subscriptions open, and produce bounces. > Most of these bounces doublebounce. > Do you write to the postmaster of these domains? (Seems to have no effect. ) > Or just blacklist? (and possible handicap other users?) > Or just accept the fact that return-addresses usually don't work? I check all double-bounces when I find time. Spams are redirected to my spam-handling factory :-) Postmasters not accepting bounces are LARTed. Local users producing mail loops are educated. Same for local users sending enormous mails. Addressing problems are fixed. The (small) rest is dropped. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: qmail syntax problem
On Wed, Sep 20, 2000 at 12:39:31PM +0200, Magnus Bodin wrote: > Show us your contents of > > /var/qmail/control/me > > and (if it exists) > > cat /var/qmail/control/helohost And (wild guess) make sure there are no CRs in them like after transferring from a windoze machine in binary mode. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: Questions...
On Tue, Sep 12, 2000 at 04:32:52PM -0400, Michael T. Babcock wrote: > For the sake of answering the original questionner w.r.t. reasoning, from > RFC974 (which is standard 0014): > >Note that the algorithm to delete irrelevant RRs breaks if LOCAL has >a alias and the alias is listed in the MX records for REMOTE. (E.g. >REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This >can be avoided if aliases are never used in the data section of MX >RRs. > > cf. http://www.faqs.org/rfcs/rfc974.html > > This is the only mention of the non-use of CNAMEs in the mail standards. Mail standards aren't the only standards. The origin of all this fuss is probably RFC1034 (also part of STD 13): 3.6.2. Aliases and canonical names ... CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records: USC-ISIC.ARPA IN CNAME C.ISI.EDU C.ISI.EDU IN A 10.0.0.52 Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME. Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: Why qmail can not receive hotmail messages?
On Thu, Sep 07, 2000 at 01:48:00AM -0400, Adam McKenna wrote: > 2) It is *not* the frigging MX record. That has nothing to do with it. Any > mailer that breaks when there is only an A record is a broken mailer. And who says so? I'm sure every mailer SHOULD fall back to the A record, but the RFCs don't demand it. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
Re: Mail Protocol Issue: BCC only?
On Wed, Aug 30, 2000 at 08:10:29AM -0400, Scott Sharkey wrote:
> I asked a few weeks ago about known issues with qmail not delivering
> BCC messages.
I don't think that there is such a problem *in general*.
Unfortunately, I don't have your previous message handy.
> After investigating further, the client is claiming
> that the messages that are not delivered have ONLY a BCC (no to, no
> cc). In a quick reading of RFC822, it appears that there is some
> ambiguity to the spec (surprise!)... a "destination" is required,
> where destination is defined as a To:, CC: or Bcc:. But, it also
> says that the Bcc: can be put only on the author's copy, or on
> all Bcc recipients copies, but NOT on To: or CC: recipient copies
> of the message. It's optional in the first two cases.
Your analysis is correct. The only part of qmail that handles this
is qmail-inject, and it handles this case correctly by always removing
the Bcc: header and inserting a dummy, but valid Cc: header if no
Addresses are left:
if (!htypeseen[H_TO] && !htypeseen[H_CC])
puts("Cc: recipient list not shown: ;\n");
The rest of qmail couldn't care less about the contents of
previous headers. qmail will happily deliver an incoming mail with no
headers at all. It will insert its own Received: headers, of course.
The only way I can think of that qmail may drop a Bcc: mail is the
following:
An external Bcc mail comes in without any destination headers and
is fed to some script that tries to reinsert the mail without giving
new destination addresses, but that would be nonsensical, I think.
> So, in theory, a message with a BCC only would have no To:, CC:,
> or Bcc: headers, at least in some cases. Question is, is the
> message then a "legal" message, or would qmail just drop it since
> there is no "destination"? I know Dan is a stickler for observing
> correct protocol (I agree with him), but I'm not sure if this is
> a bug or "expected behavior".
There's also the important point of "being liberal in what you accept".
Could you please (re-)provide some more details, maybe it is a MUA problem.
Jost
--
| [EMAIL PROTECTED] Please help stamp out spam! |
| Postmaster, JAPH, resident answer machine am RZ der RUB |
| Pluralitas non est ponenda sine necessitate |
| William of Ockham (1285-1347/49) |
Re: SPAM From <> (was Re: Re: from: <> ???)
On Mon, Aug 21, 2000 at 04:46:32PM -0700, Aaron L. Meehan wrote: > Yes, well, in my experience the cons of blocking null senders far > outweigh the pros. The vast majority of spam is sent with forged > addresses, or take-your-pick blasted free email provider addresses. > I've been trying to convice once particular NT ISP here in Oregon of > this fact for nearly three years. > > How they can allow their users to send lots of mail--to such places as > AOL, any network for that matter that has external mail gateways that > forward to internal hosts--and when it bounces NOT know about it is > beyond me. I think it must just be ignorance of how SMTP works. I'm not sure if this is relevant here, but in my opinion every Postmaster who intentionally refuses mail because of empty envelope senders should get fired for incompetence. Reason: This breaks one of the base concepts of Internet mail. If you have configured your client correctly, and no disc crashes come in the way, for every mail you send you either get an error or it gets delivered (somewhere). The empty envelope sender is prescribed for bounces (RFC 1123), and if someone refuses such mails, he denies his users the information that their mail has failed. Not to mention I find those thing in my double- bounce folder (along with the spams). If I have time, I forward the mail to the user and something unfriendly to the postmaster. You can imagine what I think about MTA authors that even make this setting the default. Another mystery in this area is why some people think they must *relay* these mails for everyone ... The original question, however, was about From: <> in the header. That, on the contrary, is illegal in RFC and a sure sign of spam. Unfortunately, you only see it when you have taken the mail (in standard qmail). Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | Pluralitas non est ponenda sine necessitate | | William of Ockham (1285-1347/49) |
(spam-) Tagging incoming mail (was: Pass on tcpserver environment variables to qmail-queue, possible?)
> "Peter" == Peter van Dijk <[EMAIL PROTECTED]> writes: > How about something like FAQ 5.5? Here there be dragons. (Also known as "Been there, done that"). For various reasons I can't reject spam on the incoming mailhost, but I'd like to tag likely Mails with something like X-Spam-Tag: type blacklist field From origin rzrub trigger [EMAIL PROTECTED] action complain issuer sunu450.rz.ruhr-uni-bochum.de I jumped onto 5.5, put :allow,RELAYCLIENT="@UCEcheck",DENYMAIL="DNSCHECK" into my rules file, and was happy for an hour. Then I noticed that I just had started relaying for everyone. Why do you think the env var is named "RELAYCLIENT" ? I plugged this in the script, but someone used me to do relay-rejecting spam :-( I now see only two possibilities: 1. Two instances of qmail. 2. A patch to qmail-smtpd, introducing NORELAYCLIENT. Actually I did 2., but I still have to check the effects ... Anybody got a better idea? Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | non sunt multiplicanda entia praeter necessitatem| | William of Ockham (1285-1347/49) |
Re: MAILHOST and envelope sender
On Wed, Jan 20, 1999 at 05:41:06PM +0100, Harald Hanche-Olsen wrote: > In other words, it basically runs > > /usr/lib/sendmail -oi -f USER -oem -edb -t > > where USER is your login name. Right, from the manpage of qmail-inject: -fsender Pass sender to qmail-queue as the envelope sender address. This overrides Return-Path and all environ- ment variables. Jost -- | [EMAIL PROTECTED] Please help stamp out spam! | | Postmaster, JAPH, resident answer machine am RZ der RUB | | non sunt multiplicanda entia praeter necessitatem| | William of Ockham (1285-1347/49) |
