Correct. spamdyke uses the envelope sender address to construct the graylist
entry, not the "From" line from the message itself.
When the spamdyke logs say "from: (unknown)", it means the "MAIL FROM" line was
either empty or unparsable for some reason. Most often this means the command
looked like this:
MAIL FROM:<>
That's the most common way for a bounce message to be delivered. When that
happens, a graylist entry is still created using "_none" for the domain name
and "_none" for the username. So a graylist entry to me from an empty sender
would create a file named ".../silence.org/samc/_none/_none".
Peter's right that a simple measurement of DENIED vs ALLOWED will have a lot of
potential problems -- it'll look deceptively meaningful (as most statistics
do). Adding the message ID or the subject line to the logs would definitely
help a lot. Now that I've got the code in place to buffer and examine the
header lines for filtering, I intend to add logging of specific lines soon.
Overall, I suspect Eric suspects what I also believe -- graylisting isn't
effective any more. Spammers have (mostly) moved past using botnets to send
spam as stupid SMTP clients that can't handle rejections. These days they're
using botnets to send spam through "real" mail servers that use queues and
retry messages correctly.
-- Sam Clippinger
On Jul 8, 2012, at 12:54 PM, Peter Palmreuther wrote:
> Hi,
>
> Am 07.07.2012 um 21:01 schrieb Eric Shubert:
>> Looking at the log messages, I see "from: (unknown)" in some cases. I
>> presume that this is the envelope sender, while the message/internal
>> sender is used for the graylist entries.
>
> Hopefully not. I haven't had a look at the code recently, but I'd assume that
> envelope sender is the graylist relevant address.
>
> At least I'd expect it that way, because graylisting shall drop in after
> "EHLO/MAIL FORM/RCPT TO" dialog;
> And I just checked and it worked that way.
>
> So there're exactly four information available in this state of mail transfer
> conversation:
> - remote ip address / host name
> - EHLO name
> - envelope sender
> - envelope recipient
>
> And only these can and should be graylisting relevant.
>
>> I think that the simplest way of matching up messages would be if the
>> log messages contained the Message-ID field from the email headers.
>
> Unless I'm completely wrong this is neither possible (because no message
> content has been transferred yet), nor sensible.
> Imagine
>
> - sender tries to send message 1 to recipient 1
> - sender gets graylisted
> - sender tries to send message 2 to recipient 1
> - sender gets graylisted
> - sender retries message 1 after graylist timeout
> - sender gets permitted to transfer message content
> - sender retries message 2
> - sender gets permitted to transfer message content immediately
> - sender tries to send message 3 to recipient 1 within graylist expiry timeout
> - sender gets permitted to transfer message content immediately
>
> First of all Message-ID values will with current graylisting implementation
> only be logged after successfully passing graylisting.
> So to change this message needs to be transfered completely before
> graylisting steps in.
> I for myself wouldn't want it to happen, because I don't want to pay with my
> systems resources and traffic for messages I don't want to receive :-)
>
> Second for message 3 there's no graylisting delay log, because sender and
> recipient tuple is already validated.
> So, even if also logged for delayed messages, which would require changes in
> graylisting behavior, for this message there would only be one log entry and
> nothing to match with for counting "delayed vs. allowed" :-)
>
>> As always, thanks to Sam for his great work on spamdyke.
>
> Seconded :-)
> --
> Regards,
>
> Peter
> _______________________________________________
> spamdyke-users mailing list
> [email protected]
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
