[qmail] Wer benutzt qmail mit Greylisting? "mail_from" leer?

[ClausVB]

In letzter Zeit zeigt qmail mit Greylisting folgende Einträge in der MySQL-Datenbank:

+-----------------+-----------+----------------+---------------------+---------------------+---------------+
| relay_ip        | mail_from | rcpt_to        | block_expires       | record_expires      | blocked_count |
+-----------------+-----------+----------------+---------------------+---------------------+---------------+
| 194.78.209.104  |           | [email protected] | 2008-09-21 21:11:29 | 2008-10-28 23:09:50 |             1 |
| 62.116.117.149  |           | [email protected] | 2008-09-21 21:30:23 | 2008-10-28 10:28:50 |             1 |
| 192.121.67.127  |           | [email protected] | 2008-09-21 22:13:33 | 2008-10-28 12:08:37 |             1 |
| 85.125.203.4    |           | [email protected] | 2008-09-21 22:13:55 | 2008-10-27 22:20:55 |             3 |
| 217.160.219.193 |           | [email protected] | 2008-09-21 22:53:29 | 2008-10-27 22:54:44 |             4 |
+-----------------+-----------+----------------+---------------------+---------------------+---------------+

"mail_from" sollte bei standardkonformen Servern doch nicht leer sein, oder?

Sowohl ich (eigener Root-Server), als auch ein Kumpel (virtueller Server) haben das Problem.

Wer hat das Phänomen noch?

Wir überlegen uns jetzt den Quellcode von qmail zu ändern und die Mails mit leerer Mail-Adresse
a. nicht zu loggen oder zu blocken
b. in eine extra Text-Datei zu schreiben, damit wir nachvollziehen können, ob das Spam oder irgendwas anderes ist.

Danke und Gruß
Claus

 

[CentY]

Hi,

ich habe das Problem ebenfalls weswegen unser Relayserver immer mault nachdem der die abgelehnten Mails von Qmail wieder bekommt.

Sep 30 07:34:11 Sushi postfix/smtpd[12929]: warning: Illegal address syntax from qmail.server.tld[xxx.xxx.xxx.xxx] in MAIL command: <#@[]>

 

[LinuxAdmin]

<>

ist die Absenderadresse des Postmaster-Accounts, der nach den RFCs besonders behandelt werden sollte. Daher wird er gerne von SPAMmern verwendet, da solche Mails immer zugestellt werden sollten....

 

[ClausVB]

ist die Absenderadresse des Postmaster-Accounts, der nach den RFCs besonders behandelt werden sollte.

Ganz leer finde ich dazu keine Bestätigung, vielleicht kannst Du mir sagen, wo Du das gelesen hast.

Gefunden habe ich (über Google) folgendes:

Any system that includes an SMTP server supporting mail relaying or
delivery MUST support the reserved mailbox "postmaster" as a case-
insensitive local name. This postmaster address is not strictly
necessary if the server always returns 554 on connection opening (as
described in section 3.1). The requirement to accept mail for
postmaster implies that RCPT commands which specify a mailbox for
postmaster at any of the domains for which the SMTP server provides
mail service, as well as the special case of "RCPT TO:<Postmaster>"
(with no domain specification), MUST be supported.

SMTP systems are expected to make every reasonable effort to accept
mail directed to Postmaster from any other system on the Internet.
In extreme cases --such as to contain a denial of service attack or
other breach of security-- an SMTP server may block mail directed to
Postmaster. However, such arrangements SHOULD be narrowly tailored
so as to avoid blocking messages which are not part of such attacks.

Zitat von RFC 2821 (rfc2821) - Simple Mail Transfer Protocol

=> Ein "<Postmaster>" würde ich also erwarten und ich bekomme manchmal auch Mails von "[email protected]"

Arbeitet ein komplett leerer MAIL FROM RFC-konform?

Ich weise noch einmal explizit darauf hin, dass der RFC den ich gefunden habe von RCPT TO spricht, ich aber ein Problem mit dem MAIL FROM habe.

Ich habe dazu noch RFC 821 gefunden: "A MAIL command with a null reverse-path appears as follows: MAIL FROM:<>"

Daraus bin ich aber nicht schlau geworden.

Gruß
Claus

 

[LinuxAdmin]

Ich gebe zu, "postmaster" war nicht ganz die richtige Antwort, aber der "null reverse-path" wird für Bounce-Messages verwendet, um Mailloops zu vermeiden:

If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path). Formats specified for non-delivery reports by other standards
(see, for example, [24, 25]) SHOULD be used if possible.

This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting notification messages. One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted the reverse-path MUST be set to null (see section
4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:

MAIL FROM:<>

As discussed in section 2.4.1, a relay SMTP has no need to inspect or
act upon the headers or body of the message data and MUST NOT do so
except to add its own "Received:" header (section 4.4) and,
optionally, to attempt to detect looping in the mail system (see
section 6.2).

 

[ClausVB]

Wenn ich den Text richtig verstehe kann sich ein RFC-konformer Mail-Relay so verhalten, dass wenn die Bedingung erfüllt ist:

"(...) When such a message is transmitted the reverse-path MUST be set to null (...)"

Auch GMAIL, GMX und wie die Großen alle heißen .... berechtigt wären ein

MAIL FROM:<>

zu verwenden. Demnach sollte ich qmail nicht verändern und solche Mails keinesfalls rejecten, richtig?

Man könnte jedoch über ein Perl-Skript nachdenken, dass die MySQL-Datenbank bereinigt, weil die Fälle bei uns zu 100% Spam sind. Ich würde das im Skript dann über eine Variable oder Konstante steuern. Dann hat jeder Admin selbst die Möglichkeit das ein oder auszuschalten.

Danke und Gruß
Claus