Todd Lyons wrote:
> What about an (further) enhancement to esmtp to allow rejection of
> individual recipients at smtp data time? Yeah, it adds increased
> complexity on both the sending and receiving sides, but it solves the
> problem nicely of "deliver oversized msg to everybody except $ISP".
> For the sender, it already has the ability to handle queued delivery
> of an email to one out of the entire list of recipients, so it's not
> like it isn't already capable of that aspect. As far as the receiver,
> it just needs to be able to say 4xx for a specific user (and the
> sender needs to understand it of course).
>
> Am I being too simplistic thinking that the addition of a new verb
> could solve the per-user preferences problem nicely?
>
> Regards.... Todd
General problem, not just size, but spam threholds, et al.
The protocol would need to change, as - at present - there are no 'handshakes'
nor advertising of same, for the participating machines to even communicate a
'wish' to reject some, but not all recipients for a given message.
http://www.courier-mta.org/draft-varshavchik-exdata-smtpext.txt
Sam wrote the predecessor of that over ten years ago, and further actually
included it into courier-mta, so if/as/when two of his MTA communicate, they can
actually do this already.
He was not the only such 'pilgrim', and 'Exim's own' Tony Finch also made a stab
at what would be needed. Info on both can be found online.
Ironically, local mail transport DID find accpetance, and DOES do exactly what
is wanted - BUT -specifically is fenced-off from being integrated with smtp on
that score or even presented as a public-facing service per se.
So ... until *at least* one other MTA besides courier-mta actually implements
EXDATA or the like so as to start building risk/reward, cost/benefit experience
in real-world use .. OR lmtp *is* integrated into smtp ...nothing is likely to
happen.
'Some folks' do take the BFBI exit and set their MTA to accept only one
recipient at a time .. but that is not in accordance with the RFC, ergo 'not
recommended'.
Bill
>
> On Wed, Jan 19, 2011 at 12:34 PM, Dean Brooks<dean@???> wrote:
>> On Wed, Jan 19, 2011 at 08:16:35PM +0200, Stuart Gall wrote:
>>
>>> Ideally I would like to set a size limit for the yahoo.com domain so
>>> that I immediately reject any mail> 5M with a yahoo recipient (and
>>> possibly others throwing the baby out with the bath water etc)
>>>
>>> Is there a more sensible way to do this, or a better way all
>>> together to deal with the problem.
>>
>> The difficult part in doing this with ACLs is that you wont often know
>> the message size until SMTP DATA time, but by then your only choice
>> would be to reject the entire message even if it meant rejecting all
>> the other non-yahoo recipients.
>>
>> In my opinion, a better alternative might be to use a router to handle
>> this. This has the positive side effect of automatically meshing with
>> normal RCPT verification in the event that the SIZE attribute was
>> given in the MAIL command, not throwing out all the recipients because
>> of one Yahoo recipient, and being easy to read without the use of
>> extra variables.
>>
>> Something like this right before your remote_smtp router:
>>
>> limit_size:
>> driver = redirect
>> domains = yahoo.com
>> condition = ${if>{$message_size}{5M}}
>> allow_fail
>> data = :fail: message too large
>> fail_verify
>>
>> The only other side effect I can think of is that it will generate a
>> bounce instead of an immediate rejection at SMTP time (if SIZE isn't
>> given in the MAIL command and thus caught by RCPT verification).
>>
>> This isn't a bad thing though since this would only apply to your
>> authenticated relay users and you generally dont want to do SMTP-time
>> rejection to mail clients. Some clients like Outlook will simply
>> retry delivery over and over from the outbox when it gets an SMTP
>> rejection.
>>
>> --
>> Dean Brooks
>> dean@???
>>
>> --
>> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>
>
>
