On 02/26/2013 06:31 PM, hector wrote:
Been developing and using greylisting for 9+ years in our package and
everyone loves it. You have to make it work for your customers with
advanced fast whitelisting ideas and with support for advanced "Smart"
MTA ideas like SMTPGREY
(http://tools.ietf.org/html/draft-santos-smtpgrey-02) its fits in better.
Sure there will be uses and when it helps to avoid spam, good!
I think the better approach is to "teach" the MTA how mail can be
received and delivered more efficiently without wasted retries and
delays. New SMTP extensions that attempt to inform clients about
server/hosting attributes. That will probably mean a new DNS Server
Policy discovery concept like the old Fidonet NODELIST which provided
clients delivery times and whats was allowed to be transferred to
servers. It even told clients when to use the BACKUP routing path
guaranteed by FTSC policy to be always deliverable. The SMTPGREY
proposal attempts to provide some reject intelligence to help the MTA
reschedule its 2nd try. We have proof of concept that it indeed works
in practice.
Yes, that sounds reasonable. Maybe it could even be combined with the
XCLIENT proposal, so a retry will reach the same MX. (I understand that
XCLIENT and SMTPGREY are really different beasts with different purposes.)
This is why its a complex queuing issue. Suppose I have 1000 messages
for 1000 people at the same domain? How will you do the sending? Do
all go to the first MX? Do you spread it? Are you shooting for fast
throughput? What is the better queuing strategy? Does one fit all?
The answer is in the RFC I have quoted earlier for you. All 1000
messages MUST be tried by the client using the first MX. Hate it or love
it, but that is what the RFC 5321 is for. And yes, I know, there is no
way to check / enforce that, unfortunately I would say. Maybe the
XCLIENT proposal can help in that regard.
Evert
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp